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The present application was filed on January 20, 2000 with claims 1 through 12. Claims 
1 through 12 are presently pending in the above-identified patent application. 

In the Office Action, the Examiner rejected claims 1, 4, 7, and 10 under 35 U.S.C. § 
5 102(e) as being anticipated by Cruickshank et al. (United States Patent Number 6,389,005) and rejected 
claims 2, 5, 8, and 11 under 35 U.S.C. § 103(a) as being unpatentable over Cruickshank et al., and 
further in view of Adelman et al. (United States Patent Number 6,006,259). The Examiner also 
indicated that claims 3, 6, 9, and 12 would be allowable if rewritten in independent form including all 
of the limitations of the base claims and any intervening claims. 
1 0 The present invention is directed to a method and apparatus for congestion management 

in a multi-branch Internet Protocol (IP)-based private branch exchange (PBX) switch. The multi- 
branch IP-based PBX switch is interconnected through (i) a packet network referred to as the primary 
network, such as a wide area network (WAN), and (ii) an alternate network, such as the public switched 
telephone network (PSTN). Packet phone adapters (PPAs) associated with each packet telephone unit 
15 monitor packet telephone calls and report delay information to communication servers. The 
communication server can reroute the packet telephony calls through the secondary network upon 
detection of congestion in the underlying primary network, thereby preserving voice quality. 
Independent Claims L 4, 7 and 10 

Independent claims 1, 4, 7, and 10 were rejected under 35 U.S.C. § 102(e) as being 
20 anticipated by Cruickshank et al. 

Regarding claims 1, 4, and 10, the Examiner asserts that Cruickshank teaches "a 
congestion indicator status associated with each path in said primary network, said congestion indicator 
status indicating whether said path is congested and based on congestion data from at least one device 
that participated in a packet telephony communication." 
25 Applicants note that Cruickshank teaches that a Quality of Service parameter should be 

used to determine the network on which a call should be routed. In particular, Cruickshank teaches: 




whenever a call is established over the internet, PBX 14 monitors the quality of 
service (QoS) of the internet call path (block 134). This involves measuring such 
30 parameters as packet delay, the number of data packets dropped and throughput 

Preferably QoS is measured using the known Real-Time Transport Control Protocol 
(RTCP). 
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Col. 2, lines 32-36. 

Thus, Cruickshank monitors QoS parameters such as packet delay, packets dropped and throughput. 
Cruickshank does not address the monitoring of congestion. 
5 Applicants note that there is a significant difference between the monitoring of the QoS 

parameters taught by Cruickshank and the monitoring of congestion, as required by the present 
invention. The QoS parameters cited by Cruickshank do not accurately predict congestion and vice 
versa. 

For example, the QoS parameters cited by Cruickshank can falsely determine that there 

10 is congestion within a path of a network when, in fact, congestion does not exist. Consider the case 
where a "packets dropped" parameter drops below a minimum quality of service threshold. In some 
cases, this could be the result of buffer overflow at an outgoing network link due to congestion. In 
other cases, dropped packets could be the result of corrupted packet headers due to bit errors occurring 
in the network (especially in wireless networks) or the result of an overloaded receiver, even though 

1 5 congestion was not present in the network. Thus, when the "packets dropped" parameter drops below a 
minimum threshold, it is not necessarily an indicator of congestion. 

Similarly, while a long packet delay parameter can be indicative of congestion if it is the 
result of relatively full buffers on outgoing network links, it could also be the result of delays in sending 
the packet to the network from the packet's source, or could result from complex packet processing 

20 tasks required at intermediate network nodes, such as firewalls, even though congestion was not present 
in the network. Thus, packet delay is not necessarily an indicator of congestion. 

Similarly, the use of the QoS parameters cited by Cruickshank can falsely determine that 
there is no congestion within a path of a network when, in fact, congestion does exist. For example, 
upon a network congestion condition, packets will be dropped in the short term and there will be a 

25 temporary improvement in the QoS parameters. Such improved QoS parameters, however, are not 
indicative of no congestion, but rather, merely reflect the fact that packets were dropped and there was a 
temporary improvement in network conditions. The effect of dropping packets could result in a shorter 
packet delay for the packets that remain in the network, a condition typically associated with no 
congestion. Thus, the shorter packet delay could falsely indicate that congestion does not exist when, in 

30 fact, there is network congestion. 
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Independent claim 1 requires "a congestion indicator status associated with each path in 
said primary network, said congestion indicator status indicating whether said path is congested;" 
independent claims 4 and 10 require setting "a congestion indicator flag associated with said path if 
said congestion data indicates that a path associated with said packet telephony communication is 
5 congested;" and independent claim 7 requires "reporting said congestion data to a centralized server 
that performs overload control, whereby said centralized server evaluates said congestion data to 
determine if a path associated with said packet telephony communication is congested." 

Thus, Cruickshank does not disclose or suggest a "congestion indicator" or "congestion 
data," as required by independent claims 1, 4, 7, and 10. 
10 Dependent Claims 2-3, 5-6, 8-9 and 11-12 

Dependent claims 2, 5, 8, and 11 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Cruickshank et al., and further in view of Adelman et al. Claims 2-3, 5-6, 8-9 and 
11-12 are dependent on claims 1, 4, 7, and 10, respectively, and are therefore patentably distinguished 
over Cruickshank et al. and Adelman et al. (alone or in any combination) because of their dependency 
15 from amended independent claims 1, 4, 7, and 10 for the reasons set forth above, as well as other 
elements these claims add in combination to their base claim. The Examiner has already indicated that 
claims 3, 6, 9, and 12 would be allowable if rewritten in independent form including all of the 
limitations of the base claims. 

Conclusion 

20 All of the pending claims, i.e., claims 1 through 12, are in condition for allowance and 

such favorable action is earnestly solicited. 

If any outstanding issues remain, or if the Examiner has any further suggestions for 
expediting allowance of this application, the Examiner is invited to contact the undersigned at the 
telephone number indicated below. 
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The Examiner's attention to this matter is appreciated. 



Date: November 25, 2003 



Respectfully submitted, 

Kevin M. Mason 
Attorney for Applicant(s) 
Reg. No. 36,597 
Ryan, Mason & Lewis, LLP 
1300 Post Road, Suite 205 
Fairfield, CT 06824 
(203) 255-6560 



